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INT31QDUCTI0N 


Compurar  Integrated  Manufacturing  (CIM)  includes  activitias 
for  supporting,  planning,  and  controlling  tiie  manufacture  oz 
products.  Our  definition  of  a CIM  system  is  one  that  is  capahla 
of  supporting  the  total  manufacturing  process,  from  specification 
through  production,  and  retaining  the  information  generated  for 
later  analysis  or  reuse.  The  objective  of  CIM  is  to  improve  tns 
aquisition  and  dissemination  of  msmufacturing  information  and 
thus,  improve  manufacturing  effectiveness  and  resource  utilization 
that  encibles  an  enterprise  to  compete  economically. 

At  this  time,  computer-aided  systems  and  methods  exist  to 
support  some  manufacturing  functions.  Newer  methods  such  as  trial 
fitting  of  orders,  net  change  planning  and  rough  cut  resource 
planning  are  expanding  the  capabilities  of  CIM  [KCC32].  Most  of 
these  systems  and  methods  have  been  designed  and  used  to  support 
individual  memufacturing  functions  only.  The  result  is  a limited 
interaction  among  the  different  component  functions  of  CIM.  Con- 
sequently, a totally  integrated  manufactxiring  system  does  not  yet 
exist. 

In  a recant  sur’/ey  of  CAM  [HATSS],  software  integration  was 
identified  as  the  technology  with  the  greatest  potential  to  make 
CIM  a reality.  To  realize  the  benefits  promised  by  CIM,  the  fully 
integrated  manufacturing  system  must  1)  linJc  the  activities  on 
the  shop  floor  with  the  design,  planning,  and  manufacturing  engi- 
neering functions,  2)  provide  an  accurate  and  timely  feedback  from 
the  factory  floor,'  and  3)  modify  and  replan  activities  in  near 


real-time  based  on  the  actual  performance  feedback* 

Central  to  the  fully  integrated  manufacturing  system  is  th4 
data  administration  system  whose  function  is  to  manage  the  sharsd 
data  resources  throughout  the  design,  planning  and  manufacturing 
processes.  The  issues  of  representation,  integration,  and  adminis* 
tration  of  CAD/CA21  data  have  been  identified  as  some  of  the  major 
problems  in  CIH  [Y0S31] . Recent  efforts  in  manufacturing  integra- 
tion such  as  the  NASA  IRAD  and  the  Air  Force  ICA21  projects  [FYLSC, 
IGA79]  have  stressed  the  importance  of  data  management  in  CZli  iy 
concentrating  resources  on  the  study  and  development  of  database 
management  techniques. 

This  paper  presents  a distributed  database  management  system 
architecture  to  support  integrated  manufacturing.  The  svstam 
was  designed  to  support  the  Automated  Manufacturing  Rasaarcb 
Facility  (AMRF)  under  development  at  the  National  Bureau  of 
Standards  (NBS) , a representative  CIM  effort.  A prototype  of  this 
system  is  under  development  in  that  facility. 

•The  remainder  of  this  section  summarizes  the  salient  features 
of  the  NBS  project.  In  section  2,  we  discuss  the  unusual 
requirements  of  the  A21RF  amd  the  implications  of  these  require- 
ments on  the  management  of  data  in  a CIM  system.  Section  3 
presents  the  overall  design  of  a database  administration  system 
architecture  for  CIM,  evolved  from  our  understanding  of  these 
requirements.  In  section  4,  we  describe  in  seme  detail  the  major 
modules  of  this  system.  Section  5 presents  various  scenarios  of 
the  data  administration  system  in  operation,  using  the  AMRF  as  in 
example.  Section  6 summarizes  the  featiires  of  the  proposed  arohi- 
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tactura,  provides  a sratus  r9por*o  and  indicaras  the  diracoicn 
fuO^ira  efforts. 

1.1  TH2  AilR?  AND  ITS  OBJZCTrTDS 
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The  National  Biiraau  of  Standards  Automated  Mamufacturing 
Research  Facility  is  being  developed  as  a testbed  for  automated 
small  batch  manufacturing  [SIN82,  MCLSj].  It  will  be  used  uo 
support  experimenration  in  automated  metrolcgy  and  factor"/ 
integration.  The  overall  goals  of  the  ANRF  are 2 1)  to  identify 

potential  standards  amd  interface  protocols  for  automated  manufac 
turing,  and  2)  to  further  measurement  techniques  and  develop 
standard  reference  materials  which  provide  a means  of  ensuring 
traceability  of  processes  and  products  to  national  standards. 
The  specific  goals  of  the  ANRF  data  management  effort  are  twofold: 
1)  to  support  the  data  needs  of  the  A2CIF,  and  2)  to  identify  and 
prototype  data  management  interface  protocols  which  are  suitable 
to  the  cm  environment.  The  ANHF  testbed,  when  completed,  will  be 
made  available  for  selected  research  projects  by  the  academia, 
industry,  research  institutions,  and  other  government  agencies. 
The  testbed  will  be  capable  of  producing  a large  number  of  part 
families  similar  to  the  part  mix  found  in  a typical  machined-parts 
job  shop.  The  production  will  be  automated  from  the  transfer  of 


near  net  shape  blanks  from  inventory  to  the  delivery  of 


finished 


cleaned,  and  inspected  parts. 

The  control  architecture  of  the  AldRF  is  shown  in  Figure 
This  architecture  has  five  major  levels:  1)  Facility  control, 
Shop  control,  3)  Cell  control,  4)  Workstation  control, 
Zquipment  control.  * The  term  **manuf acturing  cell”  is  used  by  scm; 
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flexible  manufacturing  systems  and  fixed  autcma-icn  applications 
to  designate  an  equipment  cluster,  which  the  A2dP  idennifias  as  2 
’•woricstation'* . The  A21RP  architecture  reserves  the  term  '’call”  for 
the  control  system  coordinating  worl^taticns  ^__part  batch  prcduc 
tion®  The  typical  workstation  in  the  A21HP  is  configxirsd  with  a 
machine  tool,  an  industrial  robot,  automated  material  transfer 
areas,  and  an  intelligent  wcricstation  controller,  whose  function 
is  to  coordinate  equipment  level  operations.  The  control  archr= 
tectura  utilizes  hierarchical  control  techniques  rA1381j , in  which 
long  range  production  goals  are  decomposed  at  the  facility  leva: 
into  sequences  of  tasks,  which  ara  then  assigned  to  a subcrdinaoa 
control  mcdule  to  mcmage.  These  tasks  ara  further  decomposed  and 
assigned  to  lower  level  control  modules;  each  control  module  takas 
commands  from  exactly  one  higher  level  mcdule  but  may  direct 
several  lower  level  modules.  The  A2GU  project,  its  architacturs 
and  design  ideas,  has  been  extensively  described  in  the  litaraturs 
[3A^S2,  MCL33,  MIT 3- 4 , NANa4,  MCL34,  HOP83,  3GTT83j,  From  the  data 
systems  point  of  view,  two  characteristics  distinguish  tlte  A2<sr 
from  other  flexible  manufacturing  systems ; the  ability  of  tha 

workstations  to  function  autonomously,  and  the  explicit  separatict 
of  control  data  from  control  algorithms. 


2. 


DATABASE 


21A2TAG2HSNT  RBQUIH2MSNTS  ^ CCMPUTZB  INTZGRAT? 


MAOTFACrraiNG 


■Tha  design  of  a systaa  to  support  the  information  rsquirs'- 
ments  of  automated  manufacturing  is  affected  by  tbe  environment  in 
whicii  it  must  operate.  The  following  requirements , which  seem 
generally  applicable  to  any  cm  system,  have  been  expressed  in  nhe 
development  of  the  AMRT  testbed: 

a)  integration  of  heterogeneous  systems; 

b)  component  systems  with  different  data  management  abiiitiia 

c)  both  autonomous  and  integrated  operation  of  siibsystems  ; 

d)  flexible  manufacturing; 

e)  time  critical  operations;  and 

f)  use  of  adaptive  control  techniques. 


The  main  function  of  a database  management  system  in  this 
environment  is  to  provide  the  component  systems  with  access  to  the 
integrated  database  which  contains  data  necessary  to  support  the 
design,  planning,  manufacturing,  assembly,  inspection,  and  ser’/ica 
of  products.  It  must  also  provide  other  database  management 
f'onctions  such  as  integrity  and  security  control,  concurrency 
control,  error  recovery,  etc.  latabase  management  requirement - 
for  cm  follow  directly  from  the  characteristics  above  and  can  be 
stated  as  follows: 

a)  Integration  of  Hetercgenecus  Systems:  The  ccmputinc 
environment  supporting  the  factories  of  the  future  will  be  a 
network  of  heterogeneous  component  systems  acquired  from  numerous, 
vendors.  The  integrated  database  must  contain  all  daoa  useful  for 


the  ccntrol  and  management  of  the  component  systems  and  should 
serve  as  a medium  through  which  the  component  systems  communicate 
with  one  another.  The  software  system  which  manages  tea 
integrated  database  should  mask  the  differences  inherent  ic 
accessing  data  in  a heterogenous  environment.'  A high  level  data 
manipulation  language  is  needed  to  provide  a standard  format  for 
all  component  systems  to  make  database  requests.  Furthermore^  data 
translators  are  required  to  translate  the  type,  format,  and 
struct*irre  of  the  data  interchanged  among  the  component  systems. 
Command  translators  are  required  to  translate  the  queries  posed  Lt 
the  common  data  manipulation  language  into  the  cemmamds  which  can 
be  executed  by  different  underlying  data  management  software  sn 
the  cemponent  systems. 

b)  Compdnent  Systems  with  Different  Data  Management  Capabi- 
lities:  The  component  systems  in  an  integrated  factory  netwerk 

typically  have  different  data  management  capabilities.  Some  hav« 
very  capable  commercial  database  management  systems,  while  ethers 
have  only  file  servers  and  memory  resident  data.  Distributed  daca 
mamagement  software  needs  to  be  installed  on  selected  ccmpcnencs 
and  these  systems  can  be  assigned  to  perform  the  complex  functions 
for  lass  capable  components.  A query  issued  against  the  intagratad 
database  must  be  decomposed  into  database  operations  which  ara 
within  the  capabilities  of  the  system  on  which  the  data  resides 
A defined  set  of  primitive  operations,  a generalized  method  for 
representing  the  level  of  data  manipulation  ability,  and  a method 


assigning  operations  to  more  capable  systems  are  a 


needec 


orocess  recuests  in  a unirorm  manner. 
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management  system  mus*c  then  me  amie  tc  perform  final  assemrly  and 
formatting  of  tiie  data  retrieved  from  different  component  systems 
and  deliver  tte  result  in  the  desired  form. 

c)  Local  Autonomy  and  Integrated  Operation:  Whenever  new 
equipment  or  control  software  is  introduced  to  the  factory  da^a 
network,  the  control  and  data  systems  must  provide  for  the 
independent  tasting  and  sxihsequent  modular  integration  of  these 
elements.  The  same  capability  is  required  in  order  to  reinteg* 
rata  equipment  which  has  been  logically  removed  from  the  network 
for  maintenance  or  refit.  Note  that  in  the  case  of  a fully  auto- 
mated woricstation,  the  ’•independent”  test  requires  a separata 
integration  of  the  systems  within  the  workstation  into  an  autono- 
mous system  separate  from  the  integrated  factory  data  system,  and, 
more  importantly,  separata  from  the  live  production  data.  The  data 
system  within  the  independent  test  segment  must  have  the  function- 
ality to  acquire  relevant  segments  of  the  integrated  database  and 
to  manipulate  this  data.  Therefore,  an  independent  test  segment 
must  have  at  least  one  component  system  with  resident  distributad 
data  management  functions;  and  this  system  will  support  any 
functions  which  the  remaining  component  systems  cannot.  The  data 
system  as  a whole  requires  mechanisms  to  identify  and  control 
replication.  Reintegration  of  formerly  isolated  components  must 
occur  without  disrapting  ongoing  production.  local  databases  and 
data  directories  must  be  reconciled  to  resolve  the  inconsistencies 
arising  from  the  ’’partitioned’*  operation.  Thus,  integrity  control 
functions  must  be  enforced  thrcughcut  the  cperaticn  of  bcth 
integrated  and  partitioned  factory  network  and  are  critical  at  one 


To  aaXa  this  possible , 


the  dara  sys-cen 


3iust  access  aind  use  configuration  information  during  its  regular 
operation, 

d)  Flexible  Manufacturing;  Meeting  the  objectives  of  flaxibls 
manufacturing^  such  as  accommodating  unicicwn  production  demands, 
effective  resource  utilization  and  modular  expansion,  affects  tig 
data  management  system  in  numerous  ways.  Modular  expansion 
dictates  support  of  network  reconfiguration,  while  effective 
resoxirce  utilization  may  dictate  support  of  dynamic  control 
reconfiguration.  From  this  we  derive  some  precepts  for  the  data 
system.  First,  the  database  management  system  must  provide  data  to 
control  processes  in  a completely  transparent  manner, 
independent  of  the  data  location,  the  network  configuration  and 
the  current  control  configuration.  Second,  data  delivery  patns 
should  not  be  built  directly  into  the  control  structures  of  tia 
component  systems,  but  should  be  constructed  by  the  database 
management  system  from  the  current  repository  to  the  consumer  at 
the  time  that  consumer's  requirement  for  that  data  entity  is 
identified.  Third,  the  database  system  should  allow  frequent  and 
dynaimic  updates  to  the  data  directory  which  in  part  contains  nis 
information  about  system  configuration  and  data  delivery  paths. 

e)  Time  Critical  Operations;  The  systems  that  central 
shopfloor  equipment  typically  operate  in  real-time  and  have  time- 
critical  requirements  for  access  to  certain  data.  A variety  c: 
sensory  and  feedback  data  originating  in  subordinate  systems  are 
used  to  perform  conjtrol  functions.  It  is  important  for  this  dace 
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to  be  stored  locally  and  in  a 


form 

efficient 

for 

real 
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operation.  There  is  a critical  set  o: 
must  be  shared  and  the  time  criticality 
on  hew  to  distribute  this  data.  In  database  management  terms,  thij 
means  that: 

- data  units  may  have  to  be  replicated  from  one  componerj 
system  to  another; 

* conversion  between  the  local  data  representation  and  th; 
neutral  data  representation  is  necessary  and  frequent;  and 

- a local  data  directory  and  some  facility  for  accessing  anv 
maintaining  the  global  directory  must  be  provided  at  eac  ■ 
component  system. 


f)  Adaptive  Control:  The  control  system  for  integrated  manu- 
facturing^ must  be  able  to  detect  and  react  to  failures  and 
unexpected  events.  The  database  management  system  must  be  able  to 

- move  data  with  sufficient  speed  for  time-critical 
operations , 

- monitor  the  state  of  the  data  management  system  and  recover 
from  a failed  data  system  component, 

- support  the  recovery  of  component  systems  by  enforcing  data 
consistency  constraints, 

- allow  malfunctioning  components  to  be  logically  discon- 
nected, even  though  they  may  continue  to  demand  data  ser/ices,  and 

- act  as  a system  resource  to  gather  and  retain  data  abcur 
the  integrated  operation  for  later  analysis. 
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3.  TH3  DATA  HCD2L  AND  AHCHITSCTUx^  OF  'TES  INTFGHATSD 


MANUFACTURING  DATABASE  ADMINISTRATION  SYSTEM  f II^DAS 
In  the  CIM  environment,  tiie  existing  databases  are  already 
distributed  across  different  component  systems*  IMDAS  supports  an 
integrated  database  composed  of  physically  distributed  databases » 
The  construction  and  maintainanca  of  the  integrated  database 
relies  heavily  on  the  data  model  used  to  define  the  data  residing 
in  the  component  systems* 

3*1  A DATA  MODEL  FOR  THE  INTEGRATED  DATABASE 


The  user  facility  which  embodies  the  data  model  must 
balance  the  conflicting  criteria  of  simplicity,  logical 
completeness,  and  flexibility.  It  provides  for  the  description  oi 
data  definitions,  interactions  and  mappings  of  the  distributed 
databases,  the  declaration  of  integrity  and  security  constraints; 
and  the  definition  of  access  requirements.  The  data  model  used  in 
CIM  must  especially  be  able  to  support  the  complex  CAD/ CAM  data 
types  which  are  not  needed  in  business  data  models  and  must  be 
able  to  maintain  complex  constraints  and  relationships.  The  data 
model  selected  for  IMDAS  is  based  upon  the  Semantic  Association 
Model  (SAM*)  [SU33,SU35].  SAM*  is  rich  in  data  semantics  and 
contains  a number  of  constructs  for  modelling  the  ralationshios 
among  the  data  found  in  engineering,  business,  scientific  and 
statistical  databases.  The  SAM*  model  contains  several  semantio 
constructs  to  support  the  description  of  data  partitions, 
constraints  and  mappings  needed  for  distributed  functionality. 

To  describe  the  mappings  between  the  logically  singls 
integrated  databas'e  and  the  numerous  physically  distributed 


dataJDases,  tiiree  levels  of  view  definition  are  supported  by 


IIIDAS.  These  views  are:  1)  global  external  view,  2)  global 
conceptual  view,  and  3)  fragmented  view.  A global  external  visw 
defines  a segment  of  the  integrated  database  as  seen  by  a single 
control  process.  It  identifies  the  data  entities  and  associations 
used  by  the  control  process.  Thera  can  be  many  global  external 
views  defined  for  the  various  control  processes.  The  global 
conceptual  view  is  the  integration  of  all  the  external  views  and 
represents  a comprised  view  of  the  factory  database.  The  word 
’•global’*  is  used  to  distinguish  these  views  from  the  external  and 
conceptual  views  defined  in  some  component  DBMSs.  Fragmented  views 
represent  global  conceptual  data  which  are  physically  partitioned 
or  replicated  across  the  component  systems.  They  describe  ohs 
distribution  of  the  conceptual  database;  data  within  each  compc« 
nent  system  is  represented  as  a distinct  fragmented  view,  lach 
fragmented  view  maps  into  the  data  representation  supported  by  one 
local  data  management  facility  on  one  component  system.  We  refer 
to  the  fragments  of  the  global  database  which  are  distributed 
among  the  nodes  in  the  system  as  sub-databases . The  relationship 
among  the  different  views  is  shewn  in  Figure  2 . 


3.2  GLOBAL  DATA  MANIPULATION  AND  DEFINITION  Il^GUAGZS 


In  the  distributed  database  environment,  a source  system 
obtains  access  to  data  residing  on  a target  system  by  issuing  a 
database  query  which  cam  be  processed  by  the  target  system.  One 
of  the  following  two  approaches  is  used  to  achieve  this.  The 
approach  used  by  the  IPAD  distributed  database  project  [FULSO]  is 


issue  crueries  in  the  native  .ancuaca  of 


allow 


e source 


local  DBMS, 


This  systam  then  translates  the  query  inus 
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language  used  by  the  target  system  and  delivers  the  resul«ir.g 
query  .to  the  target  system.  An  alternative  requires  all  ccntrcl 
processes  to  use  a common  global  data  manipulation  language  (GDHL) 
to  issue  database  queries,  as  in  the  IGAM  IISS  project  [ICATSle 
The  first  approach  is  designed  to  recover  significant  investments 
in  applications  development  and  training  in  the  local  data  manipu* 
laticn  language.  But  it  requires  that  every  component  system  havs 
the  support  of  some  local  database  management  system  and  that 
there  is  a direct  correspondence  between  the  semantics  of  all 
query  languages  in  use.  These  assumptions  are  net  valid  in  a 
general  CIM  environment^  and  in  the  AMRP  in  particular.  Jer  this 
reason , we  have  chosen  to  use  the  • second  approach  in  the  IMDAS 
des-ign.  It  not  only  eliminates  the  single-sourca-to-multipla- 
target  translators  but  also  provides  a common  query  language  atd 
]<nown  semantics  for  all  the  component  systems.  The  IMEAS  GDI^I 
[3013 5]  has  been  designed  to  support  the  SAM*  data  model  and  is 
strongly  based  on  the  draft  proposed  ANSI  standard  database  manip* 
ulation  language  [ANS35] . 

The  data  model  and  the  global  data  manipulation  languags 
will  be  discussed  in  more  detail  in  subsequent  papers. 


3.3  DESIGN  CCNSIDIOATiaNS 

There  are  two  basic  distributed  database  managemen*: 
architectures;  centralised  and  distributed.  In  the  centralised 
architecture,  a single  central  data  administration  system  handles 
all  of  .the  control  and  data  management  functions.  Data  can  ds 


s-torad  in  either  centralized  or  distrihut 
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database  requests  are  routed  to  a central  control  nodule.  This 
architecture  is  straightforward  to  develop  and  nanage,  and  is 
being  used  in  some  partially  automated  factories.  Performance  of  a 
centralized  system  depends  on  the  number  and  activity  level  of  the 
component  systems  competing  for  ser’/ices.  Centralized  control, 
however,  is  not  suitable  for  extensive  CI21  systems  because  the 
architecture  does  not  meet  the  requirements  such  as  predictabia 
sex-zice  times  for  time-critical  operations,  and  adaptive  recovery. 
Moreover,  the  single  point  of  failure  of  the  central  system  would 
create  a serious  reliability  problem. 

In  the  fully  distributed  architecture,  every  ccmpcnent 
system  has  a data  administration  system  which  controls  and  manages 
the  . distributed  execution  of  the  data  management  requests  issued 
at  that  system  and  is  capable  of  servicing  requests  coming  from 
other  component  systems.  This  architecture  mahes  the  system  as  a 
whole  more  reliable  and  provides  each  ccmpcnent  system  wirh 
maximum  autonomy.  Unfcrtimately,  fully  distributed  centre!  cf 
database  integrity,  concurrency,  and  recovery  is  far  mere 
difficult  to  achieve  than  in  centralized  control. 

Most  fully  distributed  database  administration  sysmams 
mauiage  homogeneous  business  oriented  databases  on  identical 
computer  hardware.  As  noted  in  the  requirements  discussion,  a CIM 
system  generally  contains  heterogeneous  databases  on  dissimilar 
component  systems.  'Therefore,  the  considerations  that  lad  to  cha 
selacticn  and  use  cf  distributed  central  in  hcmccenecus  dismrib-- 
uted  database  management  systems  such  as  Distributed  INGPIS , 


System  SDD-1,  and  POREL  [WILS2,  NEU34,  C2RS4,  3RAa2]  are  not 


necessarily  valid  for  the  CXM  environment*  Implementing  a fully 
distributed  database  administration  system  on  every  henarccenecug 
component  system  in  a CIH  environment  is  more  difficult  and 'costly 
tban  implementing  it  on  many  homogeneous  systems.  And,  a signifi-* 
cant  overhead  is  involved  in  processing  data  using  a fully  distri= 
buted  control  strategy.  This  overhead  is  li:<aly  to  have  a 
negative  impact  on  the  performance  of  real-time  operations. 

The  IMDAS  design  piirsues  another  possibility;  a hybrid 
architecture  which  is  neither  completely  centralized  nor  fully 
distributed.  The  architecture  of  the  IhDAS  intends  to  capture  the 
advantages  of  both  architectures.  To  achieve  separability, 
reliability  and  recoverability,  the  IHDAS  minimizes  centralized 
functions  amd  replicates  the  software  which  implements  these 
functions.  To  achieve  cost  effectiveness,  particularly  cn  small 
systems,  IHDAS  does  not  require  full  distributed  data  ser'/iss 
capabilities  on  all  components. 

3.4  THS  RSLATIONSHI?  BETWEEN  IHDAS  AND  CIH  SuBSYSTEHS 

The  design  of  a distributed  database  management  system  fzr 
CIH  should  consider  the  relationship  among  the  three  major  topolc- 
gies  existing  in  CIH  systems:  the  Factory  Network  Tcpclcgy,  ths 
Control  Topology,  and  the  Distributed  Database  Hanagement 
Topology.  We  shall  now  discuss  the  relationship  between  chasa 
three  topologies  in  the  AMRP  and  the  IHDAS  architecture. 

3.4.1  FACTORY  NETWORK  TOPOLOGY 

The  factory  network  provides  the  means  cf  ccmmunicaticr.s 
among  the  component  systems.  As  illustrated  in  Figure  3,  the 
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A2iR5  network 


is  logically  a network  of 


ear 


svstaas 


comtuta: 


connected  to  a ccnmcn  high-speed  bus,  A boundary  is  fcrcad  at  th? 
workstations,  within  which  highly  tine-critical  traffic  occurs. 
Each  worJcstation  amd  its  equipment  are  connected  to  one  another 
through  a private  workstation  subnetwork.  Each  subnetwork  is 
connected  to  the  main  factory  network  through  a gateway.  The 
workstation  network  is,  therefore,  also  a network  of  peer  computer 
systems.  Thus  every  system  on  the  network  can  access  data  from  or 
provide  data  to  any  other  system  on  the  network. 


3.4.2  CONTROL  TOPOLOGY 

There  are  several  alternative  control  topologies  used  in 
CIH  systems.  In  the  AilRT,  the  various  control  systems  are  related 
to  each  other  in  a clear  hierarchical  structure.  As  depicted  in 
Figure  1,  the  control  topology,  with  the  exception  of  'the 
manufact-uring  engineering  functions,  is  a regular  tree  structure. 
It  is  important  to  note  that  mcst  data  enter  the  system  at  either 
the  top  level  of  the  control  hierarchy  cr  the  bottom.  At  the  top, 
the  facility  level,  orders,  part  designs  and  process  plans  are 
entered,  while  at  the  bottom,  the  equipment  level,  senscry  inform 
nation  enters  the  system,  host  of  this  senscry  data  is  consumed  at 
the  equipment  level  or  the  workstation  level  where  cperatiori 
sequences  are  executed  and  judgements  about  the  physical  wcrld  are 
made  by  comparing  the  design  and  engineering  information  vtth 
locally  acquired  sensory  information.  Both  the  engineering  data 
and  most  senscry  data  are  used  primarily  by  processes  which  do  not 
originate  them.  The  middle  layers  of  the  hierarchy  tend  to  genar' 

intermediate  data  to  oerform  cccrdinaticn  and 


ate  and  consume 


scheduling  functions  for  the  lower  layers,  and  to  provide  ode 
information  useful  in  facility  planning,  cost  accounting  and  coder 
high  level  functions. 

While  coimEmds  and  status  reports  follow  the  centre! 
hierarchy,  it  is  neither  necessary  nor  desirable  to  require  most 
manufacturing  data  to  do  so.  Forcing  a hierarchical  data  flew 
causes  **proxy  retrievals'*  by  component  systems  with  no  direco  use 
for  the  data  and  induces  propagation  delays  without  providing  any 
functionality.  For  example,  a machining  canter  at  the  equipment 
level  may  maUce  a request  for  a NC  Program  which  is  maintained  by 
a design  system  at  the  facility  level.  If  the  data  were  required 
to  follow  the  hierarchical  control  chain,  four  transfers  of  the  NC 
program  wotild  be  required  before  the  data  arrived  at  the  machining 
canter.  In  the  IHDAS,  the  data  flow  is  not  required  to  follow  tns 
control  hierarchy.  Instead,  the  control  information  idanrifias 
the  needed  data  sets  and  the  consuming  process  directly  acesssas 
the  actual  data. 

3,4.3  DISTHI3UTFD  DATABASE  MANAGZMZirr  TOPOLOGY 

The  IHDAS  consists  of  three  service  layers,  each  of  which  is 
responsible  for  a defined  set  of  distributed  data  managemsm 
functions.  These  functions  are  distributed  over  nhe  cempenant 
systems  according  to  their  computational  capabilities.  The  differ- 
ent layers  of  I21DAS  software  work  together  in  establishing,  manip- 
ulating and  controlling  the  distributed  databases.  The  IZIDAS 
provides  each  component  system  with  one  or  more  classes  of  dace 
management  ser’/ices.  These  classes  are  referred  to  as  ’’basic", 
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'•distributad** , and  ’'nastar^* . 


The  basic  data  management  services  - command  transiaoisn, 
data  translation  amd  communication  - are  r squired  to  provide 
access  to  the  data  residing  on  every  component  system.  These 
services  aire  provided  by  a Basic  Data  Administration  System  (3DAS) 
which  is  implemented  and  installed  on  every  component  system. 

The  distributed  database  control  and  management  func"oicns  - 
query  translation,  distributed  query  execution,  and  final  result 
assembly  - are  handled  by  the  Distributed  Data  Administration 
System  (DDAS) . This  software  resides  on  component  systems  that 
are  powerful  enough  to  support  it.  Not  every  system  has  a DDAS 
but  every  system  and  thus  every  control  process  has  access  to  one. 

The  MDAS  performs  the  functions  of  global  directory  manage- 
ment, data  system  initialization  and  data  reconciliation.  Th:-: 
''master*^  layer  of  data  management  services  is  required  when  groups 
of  component  systems  containing  more  than  one  DDAS  are  integrated 
into  an  operating  segment  of  the  factory  data  network.  Jor  each 
independently  operating  segment,  there  is  exactly  one  Master  Data 
Administration  System. 

The  IZIDAS  architecture  is  formed  by  a three-level  hierarchy 
of  3DAS,  DDAS,  and  MDAS  modules,  as  shown  in  figure  4.  Zach  module 
in  the  hierarchy  controls  access  to  data  within  its  domain,  that 
is,  within  the  entire  sub-tree  rooted  by  that  module.  Database 
management  operations  are  confined  to  the  domain  of  a module  if 
they  can  be  performed  by  that  module.  Otherwise,  they  are  passed 
upward  to  the  next  higher  level  module  for  processing.  This  archt* 
tecture  and  processing  strategy  allow  most  database  functions  to 


be  carried  out  locally  (i.e.  within  a module’s  domain)  wirhcut 
causing  unnecessary  inter-processor  communication,  synchronizatisi: 
and  data  transfers. 

As  illustrated  in  figure  5,  the  integrated  database,  whisn 
is  physically  distributed  over  the  different  component  systems, 
together  with  the  3DAS,  DDAS,  and  HDAS  modules  of  the  HiLkB 
serves  as  a central  core  through  which  all  the  CIH  subsvstsms 
interact  and  communicate. 

Figure  6 illustrates  the  relationship  among  the  IHDAS 
topology,  the  network  topology  atnd  the  control  topology,  using  tha 
AHRF  as  am  example.  In  this  figure,  two  independently  operating 
segments  of  the  factory  are  shown  with  the  three  types  ox 
topological  connections  among  the  component  systems. 


FX:rNCTIONAL  DSSCTIPTICN  OF  H^kS  MQDXJI^S 

This  sac*ticn  describes  the  modular  organization  and  func- 
tions of  the  three  subsystems  constituting  the  IHDAS ; the  Basic 
Data  Administration  System,  the  Distributed  Data  Administration 
System,  and  the  Master  Data  Administration  System. 


4.1  BASIC  DATA  ADMIMST31ATI0N  SYSTZM  (3DAS) 

The  3DAS  provides  a uniform  interface  between  the  data 
residing  on  each  component  system  and  the  integrated  database, 
Thera  is  therefore  a 3DAS  software  module  resident  on  ever*/ 
component  system  in  the  automated  factory.  Since  the  component 
computer  systems  have  widely  different  processing  capabilities, 
the  3DAS  provides  only,  the  essential  data  management  and 
communication  functions.  These  f’unctions  may  be  implemented 
differently  in  each  component  system  to  support  the  unique 
hardware  and  software  environment  of  the  system.  The  functacns  of 
the  3DAS  are  interprocess  communication,  network  communication, 
data  translation,  command  translation,  and  data  management.  The 
architecture  of  the  3DAS  is  shown  in  Figure  7, 


4.1.1  nrTFRPROCSSS  CCMMCNI CATION 


If  the  component  system  houses  multiple  control  and  sensor/ 
processes,  or  if  the  communication  and  data  management  ser’/ice^ 
are  implemented  as  separate  processes,  a mechanism  for 
communication  among  these  processes  is  needed.  Interprocess 
communication  can  be  achieved  either  by  a direct  process-co* 
process  message  passing  or  by  using  a shared  memory,  depending  on 
the  capaibilities  of  the  local  operating  system. 

The  AIIFF  uses  a shared  memory  scheme  rMIT34],  in  which  an 


originating  process  stores  inforaation  of  a particular  kind  or  for 
a particular  recipient  into  a designated  area  of  tte  sharsd 
memory,  aind  a retrieving  process  interested  in  a particular  infor- 
mation set  fetches  it  from  the  preassigned  area.  This  scheme  has 
been  implemented  on  different  systems  in  the  AliKT  in  different 
methods  - using  a true  hardware  shared  memory,  using  message- 
passing to  a memory-manager  process,  and  using  a process  which 
copies  the  information  between  the  local  memory  of  each  control 
process  and  a background  common  memory  [3AH82] 
memory  approach  permits  data  to  be  used  by  more  than  one  process 
without  explicit  action  by  the  originator  to  deliver  it  to  all 
users.  The  shared  memory  can  be  considered  as  a database  in  its 
own  right,  as  well  as  a data  communication  vehicle  between  tha 
control  processes  and  the  data  services.  The  shared  memcr/ 
approach  is  particularly  effective  in  equipment  level  systems 
which  must  perform  real-time  data  acquisition. 

4ol.2  NETWORK  COMMUNICATION 

Every  component  system  must  have  access  to  the  factory  data 
network  and  must  implement  the  protocols  necessary  to  ccmmunicats 
with  the  ether  component  systems.  The  IMDAS  architecture  presumes 
that  the  factory  data  network  utilizes  a bus  or  ring  local  area 
network  topology,  thereby  providing  a peer  relationship  between 
all  component  systems.  The  four  lowest  layers  of  the  I3C/CS1 
reference  model  [IS081]  must  be  implemented  for  each  component 
system,  either  within  the  system  or  with  network  appliances.  These 
basic  protocols  allow  reliable  communication  between  any  owe 
systems  on  the  network. 
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In  the  AxClT,  the  network  ccmnunicaticn  function  is  perfom^^u 
by  a Network  Interface  Process  (NIP)  in  each  component  r:'!iiS4]  . 
The  NI?  naps  the  needed. .areas  -of.^  a concep-tual-  - ^ ’* global ~ shared 
memory  into  the  local  shared  memory.  The  mapping  is  done  by 
replicating  the  contents  of  its  local  shared  memory  into  rhe 
shared  memory  areas  of  the  remote  components  which  require  chs 
copies  of  that  data.  The  NIP  is  table  driven^  so  that  the  mappings 
can  be  dynamically  modified  by  creating  or  destroying  entries  in  a 
'♦delivery  table'*.  The  advantage  of  this  global  shared  memory 
scheme  is  that  it  is  a distributed  database  mechanism  which  can 
both  contribute  to  and  profit  from  other  database  techniques  used 
in  the  I21DAS . 

4.1.3  DATA  T3i;^SLATI0N 

Whenever  data  are  to  be  moved  from  one  system  to  another, 
it  is  necessary  to  translate  the  data  from  the  source 
representation  to  the  required  target  representation.  The  data 
translation  process  typically  involves  the  translation  of  data 
type,  structure,  and  format  of  the  data.  This  translation  can  be 
performed  by  either  direct  source- to- target  conversion  or  source- 
to-ccmmon-to-target  conversion.  We  use  the  latter,  since  it 
requires  substantially  fewer  translators  at  each  component  system, 
one  local -to-common  and  one  common-to-local , as  opposed  to  (N-l; 


,ocal-to-tarqet  translators  for  eacJ 


1 •.«  w 


the  N systems.  Ising  th. 


approach,  the  data  translator  converts  the  data  fro: 


the  .oc: 


representation  (data  type,  format,  and  structure)  to  a '*commcr 
representation  on  '*  outbound'*  sessions  and  from  the  "commct 
reoresentation  to  the  local  reoresentation  on  '*inJ2cund'*  sessions 


For  each  '•session**,  the  data  translator  must  be  given  the  syn-aic 
of  the  messages  for  both  the  local  and  comaon  raprssenraticns . 

4*1.4  COMMAND^B^SIATiON 

In  IMDAJ,  a global  data  manipulation  language  (GDML)  gaary 
issued  by  a component  system  is  translated  into  a tree  of  standard 
primitive  operations  by  a DDAS.  The  function  of  command  transla^ 
tion  is  to  taJce  each  operation  in  standard  form  and  translana  ir 
into  the  query  language  or  access  mechanism  understood  by  ths 
imderlying  physical  data  management  tool,  which- may  be  a dara 
manager  or  file  manager.  Command  translation  can  often  be  tabls 
driven  although  some  particularly  intractable  data  structures  nay 
require  preprogrammed  procedures. 

4.1.5  DATA  MANAGZhZNT 

The  3DAS  in  each  component  system  must  provide,  through 
local  database  or  file  management  system,  the  actual  access  to  and 
manipulation  of  the  local  databases.  The  database  manipulation  and 
management  capabilities  can  vary  substantially  from  one  system  os 
another,  depending  on  the  facilities  provided  by  the  software.  In 
small  control  systems,  the  local  database  may  be  implemented  only 
in  the  main  memory  and  managed  by  a shared  memory  management 
process.  In  others,  a file  manager  may  meet  all  local  require- 
ments, giving  the  system  little  more  than  "read'*  and  "write'* 
operations.  In  larger  systems,  sophisticated  database  management 
systems  may  provide  the  actual  database  ser’/ices.  Horecver,  there 
may  be  more  than  one  such  facility  on  a single  component  system. 

The  sequence  " of  primitive  operation  commands  given  to  2 


3DAS  conmand  translator  must  be  within  the  capabilities  of  the 
underlying  data  nanagenent  system  which  manages  the  data.  The  da  :j 
manager  must  also  be  capable  of  cooperating  with  the  other 
managers  in  controlling  and  maintaining  consistency,  concurrency, 
and  recovery.  The  minimal  data  manipulation  capabilities  of  a 
3DAS  are  therefore  '*read  file'*  and  ’’write  file'*,  and  the  minimal 
control  capabilities  are  ’‘Icck  file'*,  and  ’’unlock  file”« 

4.1.6  3A3IC  SZRVZCZ  SXZCUTrTS 

The  function  of  this  element  is  to  provide  a single  point  cf 
contact  between  the  DDAS  and  the  3DAS  data  services.  The  basic 
service  executive  accepts  DDAS  commands,  routing  them  to  the  3CA5 
modules  which  perform  the  commaind  translation,  data  manipulation, 
and  data  translation  functions.  It  also  constructs  local  data 
delivery  paths,  sequences  the  execution  of  query  tree  operations, 
and  reports  the  completion  or  error  status  back  to  the  DDAS  trans* 
action  manager. 

The  Sasic  Ser^/ica  Executive,  because  it  communicates  with  the 
DDAS  and  with  its  peer  SSEs  must  have  a standard  set  cf 
interfaces.  The  interfaces  to  the  subordinate  3DAS  modules  are  ts 
some  extent  determined  by  the  local  system  conventions . 


4.2  DISTIIIBUTED  DATA  ADMINIST31ATICN  SYSTEH  (DDAS) 

The  DDAS  provides  control  and  user  processes  (its  users: 
with  ’tnifcrm  access  to  the  integrated  database.  Each  DDAS  is 
responsible  for  providing  data  management  ser’/ices  to  ever/ 
trocass  within  the  ccmocnent  svstems  assicned  to  it.  It 


trcvides 


and  controls  the  d 


latarase  managama’ 


functions  for  all  the  data  maintained  by  the  BDASs  on  -hsss 
component  systems.  In  each  separable  group  of  component  systems 
i.e.  each  group  capable  of  independent  operation,  at  least  om 
system  must  contain  a DDAS.  The  major  modules  of  the  DDA5  are: 
the  distributed  service  executive,  the  data  manipulation  language 
service,  the  query  mapping  service,  the  transaction  manager,  the 
data  director/  service,  and  the  data  assembly  process.  Figure  3 
illustrates  the  interrelationship  among  these  modules . 


4.2.1  DISTRI3UT2D  SZ31VIC2  SXZCUTr'/Z 

This  module  oversees  all  DDAS  activities  and  provides  ona 
single  point  of  contact  between  the  data  system  and  some  set  oi 
users  and  between  the  DDAS  and  the  MDAS-.  It  is  responsible  far 
initialization  of  the  DDAS  and  its  s^lbordi■nata  BDASs  and  fcr 
coordination  of  all  DDAS  functions. 

Whenever  a DDAS  is  brought  up,  it  must  initialize  its  data 
director/  to  reflect  only  the  data  which  is  resident  in  the  local 
3DAS.  It  then  creates  connections  to  its  subordinate  remote  BDASs, 
requests  and  incorporates  their  data  director/  information, 
(Directory  entries  of  a siibordinate  3DAS  data  or  file  manager  ara 
not  accessible  if  the  subordinate  is  down  and  must  be  integrated 
with  the  others  when  it  comes  up.)  The  result  of  the  intacraticn 
is  a conceptual  view  of  the  entire  sub-database  constituting  the 
domain  of  the  DDAS.  This  view  represents  a comprised  view  of  the 
3DAS  siib-databases , in  which  all  conflicts  and  inccnsistencaes 
existing  in  the  3DAS  directories  are  resolved.  The  DSZ  than  waits 
for  a connection  reouest  from  the  aooointed  I’lDAS . uocn  .-r.r-p--- 


ticn,  tha  MDAS  raquests,  and  the  DSZ  transmits^  zhe  rssolvad  DDAJ 
dirac"CcrY  for  innagration  into  the  Master  directory,  con'caining 
the  definition  of  the  global  conceptual  view  and  the  napping  tc 
the  fragmented  views  of  the  participating  DDASs.  The  DDAS  would  an 
this  time  execute  any  MDAS-issued  transactions  for  recovery  sr 
integrity  purposes  to  bring  the  global  danabase  no  a consisnann 
state.  Finally,  the  DS2  initializes  the  interfaces  to  the  control 
processes  served  by  the  DDAS  and  is  then  ready  to  begin  accepting 
requests  for  service. 

User  processes  running  on  the  DDAS  component  systems  issue 
data  management  transactions  (often  called  ’’queries**,  even  though 
they  may  be  update  requests)  through  the  local  or  network  inter ■= 


orocess  commimicaticn  services. 


Uoon  receiot  c; 


from  ■ a user  process,  the  DSZ  routes 


transac" 


e transaction  to  the 


;ata 


f it  can. 


Manipulation  Language  Ser/ice,  and  then  determines  whethe: 
transaction  can  be  locally  executed. 

the  transaction  to  the  Query  Mapping  Ser'/ice  and  then  on  to 
Transaction  Manager  for  execution.  If  the  tran; 
locally  executed,  the  DSZ  sends  it  to  the  MDAS  for  ser^/ice 
execution  of  the  transaction  is  complete,  the  DSZ  reports 
completion  status  to  the  originating  user. 

The  DSZ  must  also  service  transactions  originating  from  ctl 
DDAS  domains  which  are  passed  to  this  DDAS  by  the  MDAS  Transaction 
Manager.  The  DSZ  routes  such  transactions  to  the  Query  ^-lapping 
Service  and  the  local  Transaction  Manager  and  reports  completion 
to  the  MDAS  Transaction  Manacer. 


the 
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4*2«2  DATA  MANIPULATION  lANGUAGS  (DML)  SZK7ZCE 


The  DBAS  receives  transachicns  expressed  in  the  GD2CL  frcs 
the  user  or  control  processes  within  its  dcnain.  A GDML  query  is 
issued  against  the  global  external  view  of  the  integrated  datahasa 
by  the  user  process.  To  process  the  query,  IHDAS  can  either 
materialize  that  data  defined  in  the  .external  view  and  then 
perform  the  query  operations  on  the  data,  or  modify  the  query 
tree  so  that  the  query  operations  will  operate  on  the  data  defined 
in  the  global  conceptual  view.  We  chose  the  query  mcdificarion 
approach  for  its  flexibility  and  efficiency. 

The  DHL  Server  parses  the  GDML  query  into  a tree  of  primi* 
tive  operations  on  the  external  view  (an  extended  ser  o; 
relational  algebraic  operations)  and  then  modifies  the  query  tri€ 
to  incorporate  the  mapping  from  the  ext e-mal  view  to  the  global 
conceptual  view.  In  addition,  the  DHL  ser'/er  encodes  into  nha 
query  tree  data  delivery  operations,  which  reference  the  usar^ 
designated  source  or  destination  data  areas.  The  query  tree  may 
be  then  fiirther  modified  to  incorporate  security  constraints  ds« 
fined  as  part  of  the  global  conceptual  view.  The  modified  query 
tree  now  constitutes  a transaction  on  the  global  conceptual  view, 
representing  the  user’s  request  modified  by  the  constraints  on 
that  user. 

The  DHL  Ser/er  then  identifies  whether  the  requested  opera- 
tions  can  be  performed  entirely  by  this  DDAS,  by  examining  tha 
leaves  of  the  query  tree  (which  represent  the  referenced  relations 
and  attributes)  and  consulting  its  directory  to  see  if  the  data 
referenced  by  the  query  reside  in  its  component  systems.  If  any  of 
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zha  data  rafarancad  ara  cut  of  this  DDAS  domain,  the  quary  in 
translated  form  is  flagged  for  transmission  to  the  >!DAS  for 
fTirther  prccassing.  Otherwise,  the  query  is  flagged  for  process ing 
by  the  local  Query  Mapping  Service. 

Diiring  the  above  operations,  the  DHL  server  mahas  use  of 
viaw  and  constraint  mapping  information  and  data  Icca  w >«y  «n<« 
tion  provided  by  the  local  Data  Directory  Ser^/ice. 

4.2.3  QTTEHY  MAPPING  SSPVICi:  (QMS) 


This  service  accepts  from  the  DSD  query  trees,  as 
translated  by  the  DML  Server,  which  can  be  satisfied  entirely 
within  the  sub-databases  of  this  DDAS.  These  queries  may  havt 
come  from  local  users  or  from  remote  users  via  the  MDAS.  The  Quary 
Mapping  Service  decomposes  each  query  into  one  or  mere  queries  on 
the  fragmented  views  reflecting  the  partition  of  data  across 
subordinate  3DAS  databases  and  the  capabilities  of  the  data  ser- 
vers managing  those  databases.  At  this  time,  integrity  constraints 
defined  in  the  mapping  from  the  global  conceptual  view  to  the 
fragmented  views  are  incorporated  into  the  query  tree.  The  result- 
ting  query  tree  represents  a transaction  whose  execution  will 
guarantee  that  the  distributed  database  will  be  in  a consistent 
state.  The  query  tree  is  than  restr'oetured  and  optimised  sc  that 
the  query  tree  consists  of  an  optimum  sequence  of  operations.  The 
optimised  query  tree  is  organised  into  subguery  trees,  each  of 
which  can  be  executed  by  a single  subordinate  3CAS  command  trans- 
lator. The  intermediate  and  final  data  assembly  of  3DA3  results 
constitutes  another  subtree,  which  is  assigned  to  the  data  assem- 
bly ser^/ice  in  the  DDAS.  The  subquary  trees,  including  inter- 
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aediate  and  final  delivery  operations,  and  precedence 
ships,  are  now  passed  to  the  transaction  aanager  for  esactticn. 
During  the  query  modification  and  optiaitation  steps  above,  otg 
QMS  uses  data  locality  information,  profile  inforaation  (the 
amount  of  data  at  each  node)  and  BDAS  command  translator  capahi- 
lity  inforaation  provided  by  the  local  Data  Directory  Service. 

4.2.4  TRANSACTION  MANAG2R  (TM) 

The  transaction  aanager  performs  the  control  and  aanageaer.t 
of  distributed  query  execution,  including  enforcement  of  database 
integrity,  concurrency  control  and  recovery.  The  integrity  control 
mechanism  of  the  TM  realizes  a serial  execution  schedule  far  each 
transaction  received  from  the  Query  Mapping  Server,  while  insuring 
that  • the  transaction  is  processed  as  an  atomic  unit  of  recover*/. 
The  recovery  facility  of  the  TM*  brings  the  database  back  to  a 
consistent  state  after  a system  failure  or  a violation  of  oha 
integrity  constraints  has  been  detected.  The  TM  terfcras  rhe 
v-ransaction  and  database  recovery  by  selectively  delecatinc 
recovery  actions  to  the  3CASs,  by  properly  maintaining  distributad 
checicpoints,  and  by  directing  parallel  activities  of  the  BDASs 
using  the  two-phase  commit  protocol,  as  necessary.  The  concurren- 
cy control  mechanism  detects  conflicts  beuveen  active  and  oendinc 
transactions  by  identification  of  common  attribute  references. 
Pending  transactions  which  would  conflict  wiuh  active  transactions 

are  deferred,  held  in  the  t:i  and  released  when  the  conflistinc 
^ransacziGn  ccmpletas. 

When  a transaction  is  released,  the  TM  transmits  the  orotar 
sub-trees  of  the  query  tree,  along  with  the  directions  do: 
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stmcting  dalivary  paths,  to  the  proper  SDASs  (3SZs)  , using  local 
or  network  ccnauni cation  servicas,  dapending  on  whara  uhe  3DA5 
resides.  The  TH  oversees  the  distributed  execution  of  these  cper* 
ations,  receiving  status  reports  from  all  of  the  3DASs  involved* 
When  » the  final  results  of  the  transaction  have  been  delivered  to 
the  requesting  process  or  when  the  data  is  properly  updated,  the 
TH  identifies  the  transaction  as  completed. 

Transaction  management  in  n-IDAS  must  support  net  only 
transactions  characteristic  of  conventional  database  environments 
but  also  transactions  characteristic  of  the  real-time  environment, 
which  control  and  reflect  actual  physical  manufacturing  opera- 
tions. Such  transactions  reflect  the  state  and  location  of 
objects  in  the  factory  and  aff'sct.the  perceptions  and  decisions  of 
other  control  processes.  They' include  simultaneous  updates  from 
tactile  and  visual  sensors  when  a part  is  grasped  or  simultaneous 
updates  to  coordinate  the  actions  of  a workstation  controller,  a 
robot,  and  a machine  tool  when  a part  is  being  fixtured.  In  order 
to  achieve  adequate  performance,  the  IHTAS  TH  and  the  subordinate 
3S2s  support  the  automated  replication  scheme  describe  in  an 
earlier  paper.  ^HIT34j.  The  use  of  multiple  techniques  for 
managing  concurrency  and  replication  is  under  study  for 
maintaining  data  integrity  and  its  correspondence  to  physical 
reality. 

4.2.5  DATA  DIAZCTCRY  SZR^TICZ  (DDS) 


The  DDAS  data  directory  is  built  from  the  directory  informa 
tion  provided  by  the  subordinate  3EASs  when  they  are  integrated 


It  includes  the  following  metadata: 


« the  schema  and  mapping  information  for  the  global  ccncap- 
tual  and  fragmented  views  of  data  residing  on  subordinate  BEASs, 

- the  mapping  information  for  the  external  and  conceptual 
views  of  the  data  referenced  by  the  control  processes  which  this 
DBAS  supports, 

- the  security  constraints  associated  with  the  views  of  tha 
conceptual  database  referenced  by  the  local  control  processes, 

- the  integrity  constraints  associated  with  the  data  in 
subordinate  BDASs, 

- the  profile  information  on  the  collections  of  data  at  tns 

BDASs, 

- the  data  delivery  information  required  by  the  network  and 
interprocess  communication  functions  to-  construct  delivery  paths, 

* the  information  representing  the  capability  of  each  sub« 
ordinate  DBMS  or  Command  Translator. 

When  requested  by  the  DML  server  or  the  QMS  or  the  TM,  the 
Data  Directory  Server  performs  a metadata  lookup  and  provides  data 
location,  structure,  and  delivery  information. 

4.2.6  DATA  ASSEMBLY  SERVICE  (DAS) 

This  module  performs  selection,  join,  union,  intersection, 
merging,  sorting,  and  other  final  amalgamations  of  data  retrieved 
from  subordinate  BDASs,  and  multiple  projections  of  user-provided 
data  for  distribution  to  subordinate  BDASs  for  updates.  This 
function  is  required  in  the  DDAS  to  provide  these  ser'/icas  for 
BDASs  which  have  only  limited  data  management  capabilities . It  is 
also  needed  when  data  are  retrieved  from  multiple  sources.  This 
process  assembles  the  data  and,  in  seme  cases,  reconciles  3CAB 
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data  reprasentaticns  with  the  global  ccncsptoial  rsprssentaticns 
those  data. 


4-^:3-  HAST2S  DATA  ADMINTST3l^TION  SYSTEM  (MDAS) 

The  function  of  the  MDAS  is  to  coordinate  the  activities  of 
multiple  DDASs.  'This  coordination  consists  primarily  of  managing 
the  master  data  directory,  resolving  ccncurrency  problems  among 
DDASs,  and  directing  initialization,  integration  and  recovery*  The 
software  needed  to  accomplish  this  function  is  resident  in  ever/ 
DDAS.  The  MDAS  functions  are  accomplished  using  software  modules 
largely  identical  to  the  DDAS  modules;  differences  are  concen-* 
trated  in  the  constriction  and  referencing  of  a master  director/ 
containing  the  data  definition  of  the  global  conceptual  view  and 
the  fragmentation  mappings  to  the  individual  DDASs.  Therefore,  the 
MDAS  represents  another  instantiation  of  the  DDAS  software, 
which  is  comprised  of  a query  mapping  ser/ice,  a transaction 
manager,  a data  directory  service,  and  a data  assembly  process; 
and  provides  services  from  the  master  directory  perspective.  The 
unique  2iDAS  software  element  is  the  Master  Ser/ice  Executive, 


which  oversees  global  integration,  reconciliation  and  recovery. 

The  Master  Ser/ice  Executive  treats  the  DDASs  as  its  users , 
receiving  transactions  in  the  form  of  guery  trees  referencing  the 
global  conceptual  view,  instead  of  GDICL  referencing  user  external 
views.  Dt  routes  them  to  its  QMS,  which  maps  the  global  guar/ 
tree  onto  a set  of  fragmented  views,  each  representing  that 
portion  of  the  global  conceptual  database  maintained  by  a.  single 
DDAS.  The  MDAS  QMS  is  unaware  of  the  partitioning  and  mapping  of 
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sees  the  DDASs  as  a set  of  unifora  sxibcrdinates  ^ each  of  which  has 
the  full  spectrua  of  data  management  capabilities^  and  each  c: 
which  manages  a fragment  of  the  global  conceptual  database.  The 
fragmented  view  queries  delivered  by  the  QMS  are  then  sent  to  the 
Master  Transaction  Manager,  which  distributes  the  fragments  to  the 
appropriate  DDASs  and  oversees  the  execution  of  the  query.  Whan 
the  transaction  is  completed,  the  MDAS  TM  reports  the  completicn 
to  the  MSS  e The  MSS  sends  the  report  to  the  originating  DDA3 , who 
is  responsible  for  the  commxinicaticn  with  the  originating  user* 
As  in  the  case  of  all  DDAS  operated  queries,  the  data  delivery 
operations  are  contained  in  the  query  tree  and  the  final  data 
delivery  is  direct  from  the  system  which  executes  the  root  opera- 
tion in  the  query  tree  to  the  designated  area  on  the  user's  systsn. 

While  the  Master  TM  can  use  the  conflict  detection  mechanise 
employed  by  the  DDAS  TMs,  this  mechanism,  which  successfully 
avoids  concurrency  problems  at  the  3DAS  level,  cannot  guarantee 
the  avoidance  of  concurrency  problems  at  the  DDAS  level,  because 
the  DDAS  may  be  executing  transactions  of  local  origin,  about 
which  the  21DAS  has  no  information.  For  this  reason,  the  MDAS  TM 
must  employ  a cooperative  concurrency  control  protocol  on  every 
transaction  which  is  fragmented  tc  more  than  one  DDAS. 

In  the  integrated  factory,  there  must  be  exactly  one  MDAS. 
When  the  data  system  is  initialized,  am  operator  designates  one 
DDAS  as  the  MDAS  and  directs  it  to  integrate  the  ether  DDASs. 
The  DDAS  ser^/ices  at  the  MDAS  site  continue  to  function  as  for 
any  other  DDAS.  If  an  MDAS  goes  down,  an  operator* designates  ens 
of  the  remaining  DDASs  in  the  partition  as  the  new  MDAS . The  new 
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MDAS  must  rebuild  the  master  directory  and  initiate  a recover"/ 
procedure.  When  the  data  system  is  partitioned  to  allow  a number 
of  sub-networhs  to  run  independently , an  MDAS  is  established  icr 
each  partition  containing  more  than  one  DDAS.  Each  MDAS  requests 
its  subordinate  DDASs  to  provide  their  directories  and  integrates 
them  to  form  its  own  master  directory.  When  the  sub-netwcrks  are 
subsequently  reintegrated  into  a single  data  system,  the  MDAS  uses 


the  recorded  information  to  reconcile 


5.  SCENARIO 


To  illustrata  tiia  operations  of  the  IHDAS  nodules  and  their 
functions,  we  will  present  a discussion  of  two  scenarioes  which 
use  the  A2GIF  testbed  to  describe  the  interaction  between  nodules. 
Scenario  1 illustrates  the  servicing  of  a query  from  one  conpcnent 
system  which  accesses  the  data  stored  at  another  component  systss. 
In  this  scenario,  the  query  is  issued  by  a wpricstation  control 
system  for  retrieving  the  work-in-process  data  from  a robct 
control  system  (31CS)  . Scenario  2 describes  the  processing  of  = 
GDML  query  issued  from  am  operator  interface  for  the  wcrkstaticn 
status  data  which  exists  at  more  than  one  workstati  o n .B.n  wh  e > 

SC2NAHI0  1:  Retrieval  of  Data  in  a Single  Component  System  by  a 
Remote  System 

In  this  case,  a wor3cstaticn  control  system  requests  the  part 
types  and  coiints  of  all  the  workpieces  in  a buffer  area  maintained 
by  a local  robot  control  system  (RCS) . The  workstation  will  make 
its  request  using  the  GDML.  The  following  is  a description  of  the 
different  sets  of  operations  in  the  scenario  which  represent  the 
actions  taken  by  the  IMDAS  to  process  this  qiery: 

Set  1:  1)  The  Workstation  control  program  writes  the  qrer/ 
to  its  data  service  command  area.  2)  The  3DAS  communication 
system  at  the  workstation  forwards  the  new  query  to  its  control- 
ling DDAS  by  network  or  local  interprocess  ccmmunicaticn,  depend- 
ing on  the  location  of  the  DDAS. 

Set  2:  1)  The  DDAS  Distributed  Service  Ixacutive  receives 
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the  request:  and  passes  it  to  the  DML  Ser^/er.  The  d:il  ser’/er  parses 
the  query,  references  the  directory  to  nap  nhe  wcrJ<s‘catisn 
controller  view  into  the  global  conceptual  view,  locks  up  th^-? 
referenced  entities,  builds  a query  tree  on  the  GC  view, 
determines  that  the  query  can  be  done  by  this  DDAS  and  reports  te 
the  DS2.  2)  The  DS2  passes  the  query  tree  to  the  query  napping 
server  and  the  QMS  modifies  the  query  tree  inno  a-  query  traa 
consisting  of  operations  that  the  3DAS  on  the  robot  controller  can 
execute  on  its  data.  During  this  process,  Q2iS  interacts  with  the 
directory  server  to  perform  the  napping  to  the  view  of  the  data 
held  by  the  Robot  Controller  3DAS  and  then  reports  to  the  DS2.  2) 
DS2  gives  the  resulting  query  tree,  including  the  associaoad 
delivery  information,  to  the  transaction  nainager.  The  transaction 
manager  checks  whether  there  is  any  update  of  the  workpiece  dana 
in  progress,  4)  3ased  on  the  existence  and  progress  of  the  update, 
the  transaction  manager  schedules  the  current  query  operations  sc 
that  they  will  not  conflict  with  updates.  5)  The  transaction 
manager  then  delivers  the  query  operations,  their  schedule,  and 
the  delivery  information  to  the  3DAS  at  the  Robot  Controller. 


Set  3:  1)  The  basic  ser/ice  executive  in  the  3DAS  at  th- 

RCS  receives  the  command  from  the  DDAS  to  execute  the  query.  I: 
constructs  the  data  delivery  path  back  to  the  workstation  control* 
ler,  according  to  the  delivery  operations  in  the  query,  and  passes 
the  operation  tree  to  the  command  translator  for  the  D2MS  tha“ 
manages  the  wori-cpiaca  data.  2)  The  command  translator  translates 
the  global  primitives  into  local  retrieval  commands  executable 
the  D3MS  and  interacts  with  the  D3MS  to  obtain  the  data.  2)  Ths 


the  data. 


data  tramslator  converts  the  data  into  the  i:-!DAS  standard  rspra- 
santation  and  delivers  it  to  the  Network  Interface  Process,  4)  The 
NIP  copies  the  data  in  standard  fora  to  the  peer  NIP  at  one 
workstation  and  reports  the  delivery  to  the  3SS.  5)  The  Basic 
Service  Executive  reports  the  completion  status  to  the  DDAS 
transaction  manager. 

Set  4:  1)  The  workstation  network  interface  process  delivers  tis 

woricpiecs  data  through  the  inter-process  cemmuni cation  ser^/ica  tc 
the  requesting  control  process.  2)  The  TH  at  the  DDAS  reperos 
completion  of  the  tramsaction  to  the  Distributed  Service 
tive,  which  provides  the  final  status  report  to  the  requeswing 
, woricstaticn  control  process. 


SCENARIO  2:  Retrieval  of  the  Data  Distributed  at  Hultipla 
Component  Systems 

In  this  scenario,  a GDICi  query  is  issued  by  an  operator 
interface  to  all  the  workstations  requesting  the  workstation 
identification,  the  identification  of  the  current  jcb  in  process 
and  the  expected  tine  to  complete  the  current  task.  The  data 
requested  by  this  query  are  horizontally  distributed  over  ths 
different  wor-kstation  status  reports  throughout  the  factory.  Iha 
following  sets  of  operations  occur  in  the  IHDAS  to  retrieve  the 
data: 


Set  1:  1)  The  operator  interface  pregran  writes  the 
retrieval  transaction  into  its  data  service  command  area.  2)  The 
3DAS  at  the  operator  station  recognizes  that  a new  request  exists 
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and  delivers  it  to  rhe  DDAS,  in  this  case  a local  process,  iy 
inter-process  cormiinication. 

Set  2;  1)  The  DDAS  DSZ  receives  the  request  and  passes  it 
to  the  DML  Server.  2)  The  DML  server  parses  the  request  and 
obtains  the  mapping  and  location  information  from  the  Directory 
service.  The  directory  indicates  that  seme  of  the  referenced  data 
is  not  local.  The  DML  Server  reports  to  the  DSZ  that  the  qaery 
requires  the  HDAS.  3)  The  DSZ  forwards  the  query  tree  to  the  liDAS 
via  the  network. 

Set  3:  1)  The  MDAS  Master  Ser^/ica  Zicacutive  receives  th^ 
query  tree.  It  then  obtains  the  description  and  location  infoma-- 
tion  from  its  directory  server,  which  indicate  that  the  daoa 
reside  in  multiple  DDASs.  2)  The  query  mapping  ser"/er,  using  the 
master  directory  and  the  • directory  server  performs  the  decomposi- 
tion of  the  query  into  a query  tree  of  primitive  operations  ”o 
be  performed  by  each  of  the  verkstation  DDASs,  plus  a sequence  cf 
operations  to  assemble  the  distributed  results  and  deliver  one 
final  result  to  the  operator  interface.  3)  The  MDAS  transacoicn 
manager  receives  these  sub-query  trees  and  the  delivery  informa- 
tion. It  then  checks  the  current  query  eperaoiens  for  conflicts 
wioh  the  workstation  staous  daoa  updates  ohao  miqho  be  in  progress 
at  the  different  workstaoiens . 4)  The  transaction  manager  than 
delivers  the  query  tree  of  operations,  including  delivery  informa- 
tion requesting  return  of  results  to  the  MDAS  assembly  process,  oo 
each  of  the  workstation  DDASs.  The  TM  also  sends  the  assembly  and 
final  delivery  operations  to  the  2iDAS  data  assembly  ser’/ica. 

Set  4:  1)  The- Distributed  Ser’/ioa  Ixecutiva  at  each  werksta- 


tion  DDAS  recaives  its  portion  of  the  qaery  tree  fron  zhe,  :«1DAS 
and  passes  it  to  the  local  Query  Mapping  Service • 2)  The  qhs 
assigns  the  priaitive  operations  to  the  underlying  BDASs  according 
to  the.  physical  locations  of  the  data  to  be  processed  by  tbs 
primitive  operations,  3)  The  transaction  managers  at  these  DDASs 
then  schedule  these  primitives  for  execution  and  send  these  primi- 
tive operation  commands  amd  the  delivery  information  (pointing  ts 
the  MDAS  assembly  area)  to  the  proper  underlying  3DAS, 

Set  5:  1)  The  BDASs  at  the  woricstations  with  the  data  creata 
the  delivery  path  to  the  MDAS  assembly  area,  retrieve  amd  convert 
the  data  using  commamd  translation  and  data  translation  as  in  tha 
first  scenario.  2)  The  network  communications  services  of  ths 
BDASs  deliver  the  retrieved  data  in  standard  form  to  the  network 
communication  ser^/ice  at  the  MDAS  station,  which  delivers  it  ts 
the  data  assembly  service  of  the  2ffiAS.  3)  The  assigned  operation 
completion  status  is  reported  by  the  basic  ser^/ica  executives  in 
the  BDASs  to  their  DDAS  trsmsaction  managers.  4)  Each  DDAS  trans- 
action manager,  upon  completion  of  its  subtree,  reports  the 
completion,  via  the  DSS,  to  the  MDAS  Transaction  Manager. 

Set  6:  1)  The  data  assembly  ser’/ica  of  the  MDAS  receives  the 
intermediate  data  from  the  different  workstation  BDASs  and 
performs  the  data  assembly  function.  2)  The  assembled  data  in 
final  form  is  delivered,  via  network  services  at  the  MDAS  and 
operator  interface  stations,  from  the  MDAS  assembly  service  to  the 
area  designated  by  the  originating  operator  interface  process.  2] 
The  MDAS  assembly  ser’/ice  reports  ccmpleticn  of  its  assignment  oc 
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tile  MDAS  TM , 


and  the  TM  reports  ccnplation 


f the  whole 


action  to  the  Master  Ser’/ice  ii^ecutive.  The  MSZ  in  turn 
completion  to  the  DDAS  from  which  it  received  the  request, 
the  DDAS  servicing  the  operator  interface,  '^nd  th^  DSZ 
reports  final  completion  of  the  tramsaction  to  the  operator 


face  orocess 


SUHMARY.  STATUS  AND  FUTUH5  DIH2CTI0NS 


Tha  development  of  distributed  database  management 

techniques  is  of  fundamental  importance  in  realizing  a tonally 
integrated  and  automated  factory  of  _ the  _ __future,  .. 
characteristics  of  the  CIH  environment  'introduce  database 
mamagement  requirements  which  are  quits  different  from  those  of 
other  applications.  In  this  paper,  we  have  identified  these 
requirements , amd  based  on  them  we  have  designed  an  Integrated 
Manufacturing  Data  Administration  System  (XMDAS) « 

The  IMDAS  architecture  addresses  a hetergeneous  distributed 
database  environment  for  managing  manufacturing  design,  planning, 
and  control  dataibases.  It  consists  of  a three-level  hierarchy  cf 
data  mamagement  subsystems,  the  Basic,  Distributed,  and  Master 
Data  Administration  Service  modules  (3DAS,  DDAS,  and  HDAS*)  , which 
are  distributed  over  the  component  systems  of  the  automated 
factory.  A BDAS  exists  on  every  component  system  which  can  pro- 
vide the  basic  data  management  and  communication  capabil= 
ities  necessary  to  process  data  residing  on  that  system.  The  BDAS 
modules  resolve  differences  between  their  component  systems 
and  the  ‘*IMDAS  standaird  form'* . Every  BDAS  is  super’/ised  by  exact- 
ly one  DDAS.  A DDAS,  through  its  subordinate  BDASs,  manages  all 
elements  of  the  integrated  database  residing  within  its 
domain,  and  provides  all  data  manipulation  and  data  directory 
services  on  these  elements.  The  DDAS  also  provides  the  control 
processes  within  its  domain  with  a uniform  interface  to  the 
integrated  dataibase.  Typically  a DDAS  resides  on  major  component 
systems  in  the  factory.  The  MDAS  handles  the  scheduling  and 
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arbitra-cion  of  transactions  requiring  the  cccrdina' 
nultipis  DDASs,  nanages  a global  data  diracnory,  recon 

DDAS directories,  and  controls  tbe  recovery  of  the  data 

buted  across  all  tbe  DDAS  domains.  In  every  operating 
of  the  factory,  there  is  exactly  one  MDAS.  3ut  HDAS 
are  actually  DDAS  functions  that  operate  on  the  naster 
instead  of  the  DDAS  directory,  so  that  any  DDAS  can  be  d 
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as 


dis* 


tart 


^ - 


as. 


as  the  HDASo 


The  IXDAS  is  being  implemented  in  the  M3S  testbed  in 
order  to  demonstrate  the  feasibility  of  this  design  and  to 
provide  a heterogeneous  distributed  database  prototype  for 
performing  further  research  in  data  systems  to  support  the 
factories  of  the  future.  At  the  time  of  this  writing,  most  of 
the  3DAS  functions  have  been  implemented  and  tested  on  several 
systems  including  a DEC  VAIC*,  a Sun  workstation  and  other  MC53CCC* 
based  systems,  and  Intel  Multibus-based  systems.  Considerable 
effort  has  been  put  into  identifying  uniform  interfaces  betveen 
the  various  modules.  In  the  encoding  of  query  trees  and 
responses,  a number  of  application  specific  types  have  been 
declared  using  the  ASN.l.  Seme  of  the  DDA3  f'cncticns,  such  as 
the  DML  Ser'^'er,  are  operational  and  others  are  still  'under  imple- 
mentation. The  goal  is  to  have  one  DDAS  operational  by  late 
spring  of  193  6 and  the  second  shortly  thereafter  on  the  VAIC  and 
SUN  systems  with  a globally  replicated  data  directory.  There- 
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a third  DDAS  softwara  set  will  be  irplemenusd  cn  an 


after,  a third  DDAS  softwara  set  will  be  irplemennsd  cn  an 
4300  series  system  and  the  first  MDAS  prototype  will  be  attanptad. 

There  are  a number  of  areas  requiring  further  research  ir. 
the  IMDAS  framework.  Proper  techniques  for  initialization, 
recovery  and  reconfiguration  of  the  factory  data  system  art 
critical  to  the  successful  support  of  future  CIH  envircnmen-os, 
Thera  needs  to  be  a detailed  investigation  of  these  techniques  L- 
the  context  of  their  effect  on  factory  databases. 

Factory  data  operations  often  create  or  reflect  changes  in 
the  physical  world.  The  physical  changes,  however,  have 
dramatically  different  time-scale  from  their  logical 
counterpaurts . This  presents  special  problems  in  integrioy  and 
concurrency  control  in  .the  factory  databases.  Coordination  and 
synchronization  of  distributed  transaction  * management 
functions,  and  the  proper  cooperation  between  the  data 
administration  system  and  the  control  systems  are  key  research 
areas . 


The  database  query  primitives  that  can  be  executed  by  capa* 
ble  systems  are  fairly  clear  (e.g.  relational  algebra  operations), 
However,  the  primitives  to  support  systems  with  limited  capabili* 
ties  and  the  interaction  with  mere  capable  systems  need  to 
investigated  further. 

Classifying  data  into  different  classes  and  designing  proper 
techniques  for  these  different  classes  can  simplify  the  various 
database  control  techniques  and  can  provide  better  data  management 
perf  ormcince.  An  intelligent  classification  of  the  data  ry 
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its  data  sar'/ica  racuiraaents  and  tha  design,  crganisanicn, 
placamenr  of  the  integrity  and  csncurrancy  control  nechanisns 
these  different  classes  require  acre  axperiance  with  the  na 
and  use  of  the  CAD/CAH  data. 

All  of  these  areas,  and  probably  others  yet  to 
discoverad,  are  candidates  for  future  research  in  data  systems 
factory  automation.  Construction  of  the  prototype  IHDAS, 
construction  of  the  A2CRP  itself,  is  only  the  first  step  i 
program  of  research  supporting  the  factory  of  the  futura. 
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